Vendors such as software providers, data storage providers, and the like, that provide services and issue licenses to their customers need to manage services and licenses in their systems. Traditionally, vendors would manage this task by building a distributed database with a tree-like structure, with a root node hosted by vendor.
FIG. 1 illustrates a block diagram of an exemplary conventional distributed database with a tree-like structure. As shown the distributed database 10 includes a root master node 20, a plurality of tree nodes 30A and 30B, and a plurality of leaf nodes 40A-40E. Each node is a computing device (e.g., a server, database, etc.) that includes memory configured to store relevant information regarding the services and licenses.
In traditional distributed database such as database 10, the root master node 20 is configured to manage and approve all the changes to data in the entire tree, including all other nodes 30A-30B and 40A-40E. The flow of changes at each node are indicated by a solid arrow. As shown, the changes in data made in each node first arrive at the root master node 20 and are then replicated (i.e., the dashed arrows) along the tree from the root master node 20 to the branches (i.e., tree nodes 30A and 30B) and finally to the leaf nodes (i.e., leaf nodes 40A-40E).
The approach of the distributed database shown in FIG. 1 is straightforward and allows data changes to be controlled easily. However, there are also technical disadvantages. For example, to issue any update to data, each tree node needs to maintain connectivity to the root master node 20. If a connection is not available (e.g., due to network failure, or security policies), then the change cannot not be made. Moreover, the root master node 20 has to manage changes from all nodes and becomes a bottleneck as indicated by the number of inputs and outputs to and from root master node 20. As a result, replication of changes from the root master node 20 may take significant time for complex trees. Furthermore, the changes made by one leaf of one branch are not visible to other branches until the change gets replicated through the root master node 20. In fact, even the changes made by leafs of the same branch are not visible to other leafs in the branch until the changes get replicated through the root master node 20.
Some designs have attempted to address these technical limitations by adding cross-branch replication and propagation of changes up to the root master node 20 through branches. However, such designs add a lot of complexity to the system and makes it expensive to build and maintain such a database.
Currently, for distributed databases such as database 20, there exists a need to verify that a node issuing a data change has authority to make such a change. Validating authority of a node in a different branch could be quite challenging and may require the whole tree of nodes to be replicated across the tree along with the data. Moreover, there is a need to guarantee that changed data is not corrupted or intentionally modified on the way up to root master node 20. This can be even more challenging if the data is passing through nodes deployed in the environment that are not controlled by vendor.